Reusing and Composing Tests with Traits

International audienceSingle inheritance often forces developers to duplicate code and logic. This widely recognized situation affects both business code and tests. In a large and complex application whose classes implement many groups of methods (protocols), duplication may also follow the application's idiosyncrasies, making it difficult to specify, maintain, and reuse tests. The research questions we faced are (i) how can we reuse test specifications across and within complex inheritance hierarchies, especially in presence of orthogonal protocols; (ii) how can we test interface behavior in a modular way; (iii) how far can we reuse and parametrize composable tests. In this paper, we compose tests out of separately specified behavioral units of reuse —traits. We propose test traits, where: (i) specific test cases are composed from independent specifications; (ii) executable behavior specifications may be reused orthogonally to the class hierarchy under test; (iii) test fixtures are external to the test specifications, thus are easier to specialize. Traits have been successfully applied to test two large and critical class libraries in Pharo, a new Smalltalk dialect based on Squeak, but are applicable to other languages with traits

Proposals for the Reborn Pharo Developer

International audienceSmalltalk was at the birth of current IDEs. Current Smalltalk IDEs, however, lost their abilities to adapt to developer needs (edit and jump, back button, auto-completion,...). Therefore while offering a powerful sets of tools current Smalltalk IDEs looks clunky and often lacks the application of a consistent set of guidelines. In this paper we sketch some possible IDEs future features or reorganization

A Process-Oriented Software Architecture Reconstruction Taxonomy

International audienceTo maintain and understand large applications, it is cru- cial to know their architecture. The first problem is that architectures are not explicitly represented in the code as classes and packages are. The second problem is that suc- cessful applications evolve over time so their architecture inevitably drifts. Reconstructing and checking whether the architecture is still valid is thus an important aid. While there is a plethora of approaches and techniques supporting architecture reconstruction, there is no comprehensive state of the art and it is often difficult to compare the ap- proaches. This article presents a first state of the art in soft- ware architecture reconstruction, with the desire to support the understanding of the field

Activity Report 2012. Project-Team RMOD. Analyses and Languages Constructs for Object-Oriented Application Evolution

Activity Report 2012 Project-Team RMOD Analyses and Languages Constructs for Object-Oriented Application Evolutio

Package Fingerprint: a visual summary of package interfaces and relationships

International audienceContext: Object-oriented languages such as Java, Smalltalk, and C++ structure their programs using packages. Maintainers of large systems need to understand how packages relate to each other, but this task is complex because packages often have multiple clients and play different roles (class container, code ownership. . . ). Several approaches have been proposed, among which the use of cohesion and coupling metrics. Such metrics help identify candidate packages for restructuring; however, they do not help maintainers actually understand the structure and interrelation- ships between packages. Objectives: In this paper, we use pre-attentive processing as the basis for package visualization and see to what extent it could be used in package understanding. Method: We present the package fingerprint, a 2D visualization of the references made to and from a package. The proposed visualization offers a semantically rich, but compact and zoomable views centered on packages. We focus on two views (incoming and outgoing references) that help users understand how the package under analysis is used by the system and how it uses the system. Results: We applied these views on four large systems: Squeak, JBoss, Azureus, and ArgoUML. We obtained several interesting results, among which, the identification of a set of recurring visual patterns that help maintainers: (a) more easily identify the role of and the way a package is used within the system (e.g., the package under analysis provides a set of layered services), and, (b) detect either problematic situations (e.g., a single package that groups together a large number of basic services) or opportunities for better package restructuring (e.g., removing cyclic dependencies among packages). The visualization generally scaled well and the detection of different patterns was always possible. Conclusion: The proposed visualizations and patterns proved to be useful in understanding and maintaining the different systems we addressed. To generalize to other contexts and systems, a real user study is required

Squeak by Example

Squeak by Example, intended for both students and developers, will guide you gently through the Squeak language and environment by means of a series of examples and exercises. This book is made available under the Creative Commons Attribution-ShareAlike 3.0 license

BLOC: a Trait-Based Collections Library – a Preliminary Experience Report

International audienceA trait is a programming construct which provides code reusability. Traits are groups of methods that can be reused orthogonally from inheritance. Traits offer a solution to the problems of multiple inheritance by providing a behavior-centric modularity. Since traits offer an alternative to traditional inheritance-based code reuse, a couple of questions arise. For example, what is a good granularity for a Trait enabling reuse as well as plug ease? How much reuse can we expect on large existing inheritance-based hierarchies? In this paper we take as case study the Smalltalk Collection hierarchy and we start rewriting it from scratch using traits from the beginning. We show how such library can be built using traits and we report such a preliminary experience. Since the Collection library is large, we focused and built the main classes of the library with Traits and report problems we encountered and how we solved them. Results of this experience are positive and show that we can build new collections based on the traits used to define the new library kernel

Project-Team RMoD 2013 Activity Report

Activity Report 2013 Project-Team RMOD Analyses and Languages Constructs for Object-Oriented Application Evolutio

Pharo by Example

Pharo is a modern, open source, fully-featured implementation of the Smalltalk programming language and environment. Pharo is derived from Squeak1, a re-implementation of the classic Smalltalk-80 system. Whereas Squeak was developed mainly as a platform for developing experimental educational software, Pharo strives to offer a lean, open-source platform for professional software development, and a robust and stable platform for research and development into dynamic languages and environments. Pharo serves as the reference implementation for the Seaside web development framework

A critical analysis of string APIs: The case of Pharo

International audienceMost programming languages, besides C, provide a native abstraction for character strings, but string APIs vary widely in size, expressiveness, and subjective convenience across languages. In Pharo, while at first glance the API of the String class seems rich, it often feels cumbersome in practice; to improve its usability, we faced the challenge of assessing its design. However, we found hardly any guideline about design forces and how they structure the design space, and no comprehensive analysis of the expected string operations and their different variations. In this article, we first analyse the Pharo 4 String library, then contrast it with its Haskell, Java, Python, Ruby, and Rust counterparts. We harvest criteria to describe a string API, and reflect on features and design tensions. This analysis should help language designers in understanding the design space of strings, and will serve as a basis for a future redesign of the string library in Pharo